Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Partial solution for #7 -- implementation of
yieldAll
and recursive generators through SpecSharp nested iterators.Considerations:
Needs performance measurement against original implementation (and, probably, extraction into separate API if this turns out to be considerably slower)
Increased allocation overhead by one object per iterator:
RootIterator
is allocated when iterating over the generated sequence (negligible?)Probably some optimizations are possible that simplify the iterator behavior in cases when there were no
yieldAll
calls up to some pointTail recursion can be optimized, but not in a transparent way. One option is to add separate function
generateWithTail
(or something) that would take a coroutine returningSequence<T>
Another option is to request a coroutines API that would allow one to find out that a
Continuation<Unit>
is basically a NOP that will do nothing but immediately finish the coroutine block. Once we know this about continuations we can easily optimize tail recursion.